free manual ◆ agentic coding ◆ human-first workflow

Agentic Coding Starter Manual

A free, practical manual for building with AI agents without losing the project, the goal, or the human judgment that makes the work matter.

Source of truth for: beginner-facing agentic coding manual, workflow lessons, common confusion points, and aligned free learning resources.
Last updated: 2026-06-02

Agentic Coding Starter Manual

This manual is for people who want to build real projects with AI agents without turning the chat into a pile of forgotten decisions, broken files, and half-finished ideas.

The core lesson from this product build is simple: agentic coding is not mostly about one perfect prompt. It is about giving the agent durable context, clear rules, a small next task, and a verification loop. The agent can move fast. The human has to keep it pointed at value.

Quick Index

Start Here

TLDR

If someone is new to agentic coding, give them this operating rule:

  1. Put the project memory in files, not only in the chat.
  2. Ask the agent to inspect the folder before it edits.
  3. Keep one clear "Now" task.
  4. Make the agent explain risks before building.
  5. Verify the result before adding the next feature.
  6. Use Git or another backup habit before risky changes.
  7. Do not confuse more output with progress.

The best agentic coders are not the people with the fanciest prompts. They are the people who keep the work structured enough that the agent can help without taking over the direction.

If You Are Overwhelmed

TLDR

Do not read this whole manual first. Use this section, start a tiny project, and come back when a question appears.

If the manual feels like a lot, do this:

  1. Create a folder for one small project.
  2. Create one file called PROJECT_STATE.md.
  3. Write three lines: what you are building, who it is for, and what the next useful result is.
  4. Ask the agent to inspect the folder before changing anything.
  5. Ask for one next task, not the whole project.
  6. After the task, ask what needs to be tested.

First learning outcome: the user should feel, "I know how to restart tomorrow without explaining everything again."

Learning Outcomes

TLDR

The manual should leave the reader with practical habits, not only inspiration.

After using this manual, a new agentic coder should be able to:

The DigitalQuill Trinity

TLDR

Use three questions to keep agentic coding useful instead of chaotic:

  1. Outcome: are we shipping a useful, testable result?
  2. Agency: does this make the human clearer, safer, more capable, or more in control?
  3. AI Hygiene: did the agent handle context, scope, privacy, verification, tools, and cost responsibly?

DigitalQuill uses this trinity because each lens catches a different failure mode. Agile practice catches drift and unfinished work. The Popsicle Index catches work that looks productive but does not make life better. AI best practices catch unsafe autonomy, weak verification, messy context, and overreliance on the model.

Before adding a feature, ask:

  1. What working outcome will this produce?
  2. How will this help the human make a better decision or finish something real?
  3. What needs to be verified, protected, or kept out of context?

If one answer is weak, the next task is not "add more." The next task is to fix the weak side.

The Mental Model

TLDR

The agent is a fast helper. The project needs files. The human stays responsible for direction, judgment, and final verification.

An Agent Is A Worker, Not The Project

An AI agent is a capable assistant that can read context, make plans, edit files, run tools, and report results. It is not the project owner. It does not automatically know what matters. It does not automatically know what should wait.

The human owns:

The agent owns:

The Chat Is Not Enough

Chats are temporary working space. Project memory should live in files that can be reopened, read by another agent, backed up, searched, and inspected by a human.

At minimum, every serious agentic project needs:

This is the difference between "the agent remembers" and "the project remembers."

Questions A Smart Beginner Will Ask

TLDR

Smart beginners do not need hype. They need honest answers about what to learn, what to trust, and where the boundaries are.

"Do I need to know how to code?"

Not at first, but basic literacy helps quickly. A new builder does not need to write every line by hand, but they should learn enough to recognize file types, run simple commands, read error messages, and understand what changed.

Practical target: learn enough HTML/CSS/JavaScript or Python to follow the shape of the work. The agent can fill in details, but the human should understand the project at the level of "what file owns what behavior?"

"Which AI agent should I use?"

Use the one that fits the work and your budget, but do not make the agent the center of the workflow. The project memory should be portable. If the files are clear, a future model or different tool can pick up the work.

"How much should I trust the agent?"

Trust the agent to help. Do not trust unverified output. If the agent changes files, ask what changed. If the agent claims a feature works, ask how it tested that claim.

"What should I learn first?"

Learn in this order:

  1. Markdown, because project memory lives in plain text.
  2. Git basics, because agentic coding needs checkpoints.
  3. The minimum web or app stack for the project.
  4. Prompting habits for the agent you use.
  5. Safety and privacy basics.

"What if I am technical but new to agentic coding?"

The trap for technical users is assuming normal software discipline is optional because the agent is fast. It is not. Git, tests, scope control, small diffs, and clear ownership matter more when the agent can change many files quickly.

"What if I am non-technical?"

The trap for non-technical users is treating the agent like a magic builder. It is better to treat the agent like a patient contractor: explain the goal, keep written decisions, ask what it changed, test the result, and make the next call.

The Basic Workflow Loop

TLDR

The loop is: orient, choose one task, check risks, implement narrowly, verify, record. Repeat.

1. Orient

Before editing, ask the agent to inspect the folder and summarize what it found.

Good prompt:

Explore this folder first. Tell me the project structure, what looks active, what looks risky, and what files you need to read before changing anything.

Why it works: the agent stops guessing and starts from the real project.

2. Choose One Next Task

Agentic coding gets messy when every idea becomes active. Keep a single "Now" task.

Good prompt:

Based on the current project files, what is the highest-value next task, what should wait, and why?

3. Ask For Risks Before Work

The agent should not only say how it will build the feature. It should say what can break.

Good prompt:

Before implementing, list the likely failure modes and the smallest safe implementation path.

4. Implement Narrowly

Small changes are easier to verify. They also make it easier to understand what went wrong when something breaks.

Good prompt:

Implement only the smallest useful version of this. Do not refactor unrelated files.

5. Verify

A feature is not done because the agent says it is done. It is done when the expected behavior is observed or the remaining gap is recorded.

Good prompt:

Test the changed behavior, report what passed, what failed, and what still needs my human verification.

6. Record

When the task is complete, update project memory.

Good prompt:

Update the project state, TODO, pending verification, and iteration log so the next agent can pick up cleanly.

Common Questions New Agentic Coders Ask

TLDR

Most repeated questions are not really about prompts. They are signs that memory, scope, verification, or responsibility boundaries need to be clearer.

"Can you pick up where we left off?"

What it really means: the project needs durable memory.

Better pattern: point the agent at PROJECT_STATE.md, TODO.md, DECISIONS.md, and ITERATION_LOG.md. If those files do not exist, create them.

"Why did this file or website get touched?"

What it really means: scope boundaries were unclear.

Better pattern: require the agent to name the files it plans to touch before editing. After the edit, ask for a file-by-file change summary.

"Did we ever implement that feature?"

What it really means: the project has ideas, active work, parked work, and completed work mixed together.

Better pattern: maintain a clear state vocabulary:

"Should we build this now?"

What it really means: the idea might be valuable but badly timed.

Better pattern: ask the agent to rate the idea against the current sprint goal, user value, complexity, and release risk.

"How confident are we?"

What it really means: the project needs evidence, not vibes.

Better pattern: confidence should be based on:

"Can the agent set up my account/payment/platform?"

What it really means: some work crosses into credentials, payments, or private settings.

Better pattern: let the agent prepare copy, checklist, and configuration guidance. The human should handle sensitive account actions directly.

"Why does the dashboard/app work in demo but not with my real files?"

What it really means: demo data is not a full substitute for real-folder behavior.

Better pattern: keep separate test paths:

Common Failure Modes

TLDR

Agentic coding usually fails from drift, not incompetence: unclear memory, too much scope, weak verification, parallel edits, and V2 ideas sneaking into V1.

1. Chat Memory Replaces Project Memory

Symptom: every session starts with "let me remind you what we built."

Fix: create project files and make the agent read them first.

2. Building Runs Ahead Of The Backlog

Symptom: many features exist, but nobody can say what release is trying to prove.

Fix: use a backlog with priorities. Decide what is v1, v2, parked, and out of scope.

3. Verification Debt Piles Up

Symptom: features are "code-complete" but not trusted.

Fix: keep PENDING_VERIFICATION.md. Stop adding features when too much is waiting for proof.

4. The Agent Writes Too Much At Once

Symptom: large files break, get truncated, or become hard to review.

Fix: split large files into smaller modules. Prefer external JavaScript/CSS over giant single-file dashboards when edits become risky.

5. Multiple Agents Edit The Same Files

Symptom: work collides, files drift, and nobody knows which copy is current.

Fix: one writer per file at a time. Use branches or separate work lanes for parallel experiments.

6. Browser Limits Are Mistaken For Product Bugs

Symptom: the agent says it cannot test a file picker, open a payment setting, or run a local command from the browser.

Fix: separate browser-safe behavior from native app behavior. Some things require the human, a terminal, or a desktop app wrapper.

7. V2 Ideas Sneak Into V1

Symptom: a simple release becomes sync, enterprise, telemetry, dashboards, payments, branding, and advanced analytics all at once.

Fix: keep a release rule: v1 proves the core value. V2 expands only after repeated user pain.

8. The Human Stops Challenging The Agent

Symptom: the agent agrees, builds, and adds complexity without pushback.

Fix: ask for critique:

Challenge this idea. What is the simplest reason not to build it yet?

What To Ask The Agent

TLDR

Ask for orientation, tradeoffs, smallest safe implementation, verification, and what still needs the human. Do not only ask for output.

Good Discovery Prompts

Explore the folder first. What is the project, what is active, what looks stale, and what should not be touched?
Read the project memory files and tell me the current sprint goal, blocker, and next best task.

Good Planning Prompts

Give me the smallest release-safe plan. Separate v1, v2, parked, and out-of-scope.
What would increase confidence in this project the most?

Good Implementation Prompts

Implement the smallest useful version. Preserve existing patterns. Do not rewrite unrelated files.
If you see anything funny while doing this, note it and fix only what is clearly related or low-risk.

Good Verification Prompts

Run the checks you can run. Then tell me exactly what still needs my human test.
Use a code-review stance. Lead with bugs, risks, regressions, and missing tests.

Good Strategy Prompts

Is this a v1 feature, v2 feature, parked idea, or out-of-scope idea? Explain the tradeoff.
Would adding this help buyers trust the product, or would it make onboarding harder?

What The Human Still Owns

TLDR

The agent can do a lot of work, but the human owns taste, ethics, accounts, private data, business judgment, and whether the result is actually useful.

Even with a strong agent, the human still has work.

Taste

The agent can implement a design, but the human decides whether the design feels right for the audience.

Business Judgment

The agent can explain tradeoffs. It cannot know what risk is worth taking for the business.

Sensitive Accounts

The agent can draft Gumroad copy, Cloudflare setup notes, or payment instructions. The human should handle payment methods, credentials, and final account settings.

Real-World Verification

The agent can run automated tests. The human still needs to confirm:

Final Responsibility

If the project ships, the human ships it. The agent helped. It did not become accountable.

Project Memory Files

TLDR

Memory files make the project portable across chats, agents, and time. They are the foundation of serious agentic coding.

Minimum File Set

Use this set for any serious project:

| File | Purpose | |---|---| | PROJECT_STATE.md | Current truth: phase, goal, blocker, what's solid, what's pending. | | TODO.md | Active work, next work, later work, out of scope. | | DECISIONS.md | Accepted decisions and revisit triggers. | | ITERATION_LOG.md | Dated history. Append-only. | | PENDING_VERIFICATION.md | Code-complete but not yet proven work. | | TEST_CHECKLIST.md | What must be tested before calling work done. | | RISK_POLICY.md | What needs caution, approval, or stop conditions. |

Optional But Valuable

| File | Use when | |---|---| | VALUE_LEDGER.md | You need to rank features by value, not excitement. | | WORKFLOW_MAP.md | You need to understand the user's journey through the product. | | TOOL_RECOMMENDATIONS.md | You want the agent to suggest tools without adding them blindly. | | CONTEXT_HEALTH.md | You are fighting context bloat or expensive sessions. | | TECHNICAL_PRODUCT_MANUAL.md | You need a deep handoff for technical readers or future agents. |

Rule

If a file is used by a dashboard or parser, preserve its structured markers. Do not let a compression tool or rewrite mangle headings, statuses, usage fields, or checkboxes.

Version Control And Backups

TLDR

Git is not a developer vanity tool. It is the undo system for agentic work.

Why Git Matters

Git is not just for professional developers. It is a safety net for agentic coding.

Use Git before:

Beginner Git Loop

git status
git add .
git commit -m "Describe the safe checkpoint"

If the agent suggests an experiment, use a branch:

git checkout -b experiment-name

Simple Rule

If an agent is about to change many files, make a checkpoint first.

Testing And Verification

TLDR

The faster the agent creates work, the more important verification becomes.

Verification Is Not Optional

Agentic coding creates convincing output quickly. That makes verification more important, not less.

Use three levels:

  1. Static checks: syntax, lint, build, type checks.
  2. Rendered checks: open the app/page and inspect what users see.
  3. Human checks: taste, account flows, file pickers, payment settings, real devices.

Record Gaps Honestly

If the agent cannot test something, the right answer is not "done." The right answer is:

This part passed. This part could not be tested here. Add it to PENDING_VERIFICATION.md.

Good Done Criteria

A feature is done when:

Scope Control

TLDR

Every new idea needs a timing decision. Useful later is not the same as useful now.

Why Scope Expands

Agentic coding makes new ideas feel cheap. That is dangerous. The agent can build faster than the human can validate value.

Common scope-expansion phrases:

These are not bad questions. They just need a decision gate.

The Decision Gate

For every new idea, ask:

  1. Does this improve the current release?
  2. Does it make onboarding simpler or harder?
  3. Is it valuable before users trust the core product?
  4. Can it be tested now?
  5. Is it v1, v2, parked, or out of scope?

When To Build, Park, Or Delete An Idea

TLDR

Build what raises confidence now. Park what might matter later. Decline what violates the principles or distracts from the release.

Build Now

Build it now if it:

Park

Park it if it:

Delete Or Decline

Decline it if it:

Working With Accounts, Payments, And Private Data

TLDR

Let the agent prepare and explain. The human should handle credentials, payments, permissions, and final account decisions.

Agentic coders often hit a confusing boundary: the agent can help with setup, but the human owns private actions.

Agent Can Do

Human Should Do

Good Prompt

Prepare the setup steps and tell me exactly what I need to do myself. Do not ask for or handle private credentials.

From Activist Angle To Action

TLDR

Human-first AI should not end as a slogan. Every page, post, or lesson should give the reader a next action, a learning outcome, or a way to practice more agency.

The DigitalQuill movement angle is not "AI is bad" or "use AI for everything." The useful claim is: people should own their work, spend compute intentionally, and build with tools that make them more capable.

That means every activist or mission page should answer:

  1. What can the reader do differently today?
  2. What should they learn next?
  3. What should they stop doing?
  4. How does this protect their agency?
  5. How does this help them build something real?

Convert Values Into Actions

| Value | Reader action | Learning outcome | |---|---|---| | Humans first | Ask the agent to explain tradeoffs before building. | The reader practices judgment instead of outsourcing it. | | Value over volume | Define one useful outcome before asking for more output. | The reader can tell progress from activity. | | Your work stays yours | Keep project memory in local Markdown files. | The reader understands file ownership and portability. | | Memory beats restarting | Maintain PROJECT_STATE.md and DECISIONS.md. | The reader can resume across sessions. | | Honest, not hyped | Record what was tested and what still needs proof. | The reader learns to ship with evidence. |

Page-Level Action Pattern

Every Learn or manifesto page should end with one of these:

Example Endings

For a page about AI agents:

Try this now: create PROJECT_STATE.md and ask your agent to summarize the project from only that file.

For a page about value-based spending:

Check your project: list the last three things the agent did. Which one moved the project closer to a real user outcome?

For a page about local-first work:

Learn next: read the Markdown Guide, then make one decision log in plain text.

For a page about human-first AI:

Reflect: did the tool make you more capable, or did it only produce more output?

Free Learning Resources

TLDR

Use free resources that build ownership: Markdown, Git, web basics, prompt clarity, and safety. Avoid learning paths that make the platform more important than the project.

These are free or free-to-read resources that fit the DigitalQuill principles: human-readable, practical, fundamentals-first, and useful without forcing a paid platform choice.

| Resource | Use it for | Why it fits | |---|---|---| | GitHub Skills | Beginner GitHub workflows, issues, pull requests, Markdown. | Interactive, practical, and free. Good for learning version-control habits. | | Pro Git book | Understanding Git beyond button-clicking. | Free official Git book; helps users own their project history. | | MDN Learn Web Development | HTML, CSS, JavaScript, web basics. | Strong beginner path from a trusted documentation source. | | web.dev Learn | Web fundamentals, performance, accessibility. | Free, practical, and useful for shipping better web experiences. | | The Odin Project | Full web-development curriculum. | Free, project-based, and serious enough for people who want depth. | | freeCodeCamp Learn | Practice-based coding fundamentals. | Free exercises and projects; useful for repetition. | | Markdown Guide | Learning Markdown files. | Helps users see .md files as friendly project memory, not scary code. | | CommonMark | Markdown rules and compatibility. | Useful when Markdown output needs to be predictable. | | OpenAI Prompt Engineering Guide | Prompting fundamentals for OpenAI users. | Official docs; useful for clearer instructions and task framing. | | Anthropic Prompt Engineering | Prompting fundamentals for Claude users. | Official docs; reinforces clarity, examples, and context structure. | | GitHub Copilot prompt engineering docs | Asking coding assistants better questions. | Practical examples for developer workflows. | | OWASP Top 10 for LLM Applications | Safety and security mindset. | Helps agentic coders think about risks, not only output. |

Suggested Learning Order

For a non-developer:

  1. Markdown Guide.
  2. GitHub Skills.
  3. MDN Learn: HTML and CSS basics.
  4. freeCodeCamp or The Odin Project.
  5. Prompt engineering docs for the AI tool they actually use.

For someone with an IT background:

  1. Pro Git book.
  2. GitHub Skills for pull requests and branching.
  3. MDN or web.dev for frontend refreshers.
  4. OWASP LLM Top 10 for risk awareness.
  5. Prompt engineering docs for the current agent.

Glossary

TLDR

These terms are the minimum vocabulary needed to work with agents without treating them like magic.

Agent

An AI assistant that can use tools, read files, make plans, and perform tasks.

Context

The information the agent can see during a session: chat messages, files, instructions, and tool output.

Markdown

Plain text with simple formatting markers. Good for project memory because humans and agents can both read it.

Token

A unit of text the AI reads or writes. More context usually costs more and can make the agent less focused.

Verification Debt

Work that appears complete but has not been tested enough to trust.

Local-First

A design principle where project files and memory stay on the user's machine unless the user explicitly chooses to share them.

Parked

An idea saved for later because it is not the right work now.

V1 / V2

V1 is the smallest trustworthy release. V2 is what comes after real users prove what they need next.

Checklists

TLDR

Checklists are how a smart beginner avoids relying on memory, confidence, or vibes.

Before Starting A Session

Before A Risky Edit

Before Calling Work Done

Before Adding A New Feature

Final Rule

Agentic coding works best when the human stays in charge of meaning and the files stay in charge of memory. The agent can help build the product. The workflow keeps the product from becoming a pile of output.